chore(beta): merge master into releases/v3-beta (second sync) - #5821

CONTRIBUTING.md never said what licence contributions come in under, whether a
CLA applies, or whether sign-off is required. That is a routine question for
anyone contributing from inside a company, and the answer being implicit means
each person has to ask or guess.

States the existing position rather than introducing a new one: MIT in, MIT
out, no CLA, no DCO trailer, and third-party code disclosed in the PR.

Claude-Session: https://claude.ai/code/session_01FigQqUQbNu9ngE4a2CSNm8

Co-authored-by: taliesin-ai <lea.anthony@gmail.com>

… contributions are accepted under

…nic (#5793)

fix(v3): guard nil AllowDarkModeForWindow to avoid startup panic on Windows 1809

pkg/w32/theme.go loads the undocumented dark-mode uxtheme exports (including
AllowDarkModeForWindow) only on Windows build >= 18334, so on older builds such
as Windows 10 1809 / Windows Server 2019 (build 17763) the package-level
AllowDarkModeForWindow is nil.

The Dark and system-dark branches of (*windowsWebviewWindow).run called it
unguarded, so a window with Windows.Theme == Dark (or SystemDefault while the OS
is in dark mode) panicked on startup with a nil pointer dereference before the
window was shown. w32.SetMenuTheme already guards the identical call.

Extract the call into an applyDarkMode method, which nil-guards it, and use it
from both branches so the window degrades gracefully instead of crashing.

Fixes #5792

Co-authored-by: Lea Anthony <lea.anthony@gmail.com>

…lowDarkModeForWindow to avoid startup panic

The npm package version was produced by `npm version prerelease`, which
increments the trailing numeric identifier and knows nothing about the release
channel. That is how the two series drifted: the CLI went alpha -> alpha2 ->
beta while npm kept counting alpha.N. Today the CLI is v3.0.0-alpha2.117 and
npm is 3.0.0-alpha.97, and at beta a v3.0.0-beta.0 CLI would have shipped
alongside an "alpha" runtime, with every upgrading user needing to be told the
mismatch was expected.

The runtime version now comes from v3/internal/version/version.txt, the same
file go:embed puts into the CLI, so the two always agree.

Because the version now only moves when version.txt moves, a run triggered by a
runtime source change between releases would try to republish an existing
version. Such runs now skip the publish step while still committing regenerated
assets, and version.txt is added to the trigger and detection paths so a release
that moves it does publish.

Merging this publishes nothing: a workflow-file-only change does not match the
detect job's file lists, so the publish job does not run. The next publish
happens when version.txt next moves, and it will be 3.0.0-alpha2.117 rather
than 3.0.0-alpha.98. That sorts higher, so nothing downstream breaks.

Verified: actionlint clean; version derivation exercised for both the current
master value and the beta value; the already-published guard correctly detects
3.0.0-alpha.97 as present and 3.0.0-beta.0 as absent.

Claude-Session: https://claude.ai/code/session_01FigQqUQbNu9ngE4a2CSNm8

Co-authored-by: taliesin-ai <lea.anthony@gmail.com>

Picks up the contribution terms (#5816), the release workflow hardening
(#5815), the runtime/CLI version lockstep (#5820) and the crash fixes merged
since the first sync. Clean merge, no conflicts.

The branch was six commits behind again within hours of the first sync, which
is why this is now an audit blocker rather than something to remember: a
release branch that quietly ages is how a release ships without fixes everyone
believes are in it.

Claude-Session: https://claude.ai/code/session_01FigQqUQbNu9ngE4a2CSNm8